# 接口就是：系统与系统之间，组件与组件之间，数据传递交互的通道
# 接口测试就是，对系统或组件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性
# 原理
# 接口测试，主要针对的测试目标 —— 服务器
# 怎么测？
# 模拟客户端，向服务器发送请求。
# 用什么测？
# 工具：fiddler、postman、jmter
# 代码：python + pytes框架
# 测什么？
# 测试 服务器针对客户端请求，回发的响应数据是否与预期结果一致！
            # 人眼对比
            # 断言
# 特点
    # 符合质量控制前移的理念
    # 可以发现一些页面操作发现不了的问题
    # 接口测试低成本高效益
    # 接口测试是从用户的角度对系统进行检测
# 实现方式
    # 工具：JMeter、Postman、fiddler
    # 代码：python + pytes框架
# 什么是自动化接口测试？
# 借助工具、代码，模拟客户端发送请求给服务器，借助断言自动判断 预期结果和实际结果 是否一致！

# HTTP协议简介
# 超文本传输协议，是一个基于请求与响应模式的、应用层的协议， # 也是互联网上应用最为广泛的一种网络协议。
# 协议：就是规则。要求通信的双方必须严格遵守！

# HTTP请求
# 整体格式
# 请求行：http请求第一行。请求方法 (空格) URL (空格) 协议版本  # url为资源地址
# 请求头：语法格式：k ：v
# User-Agent：描述 请求发送端的 浏览器类型。
# Content-Type：描述 请求体 的 数据类型！
# 空行：代表http请求头结束。
# 请求体：请求发送时携带的数据。数据类型 Content-Type 的值！
# post 和 put 有请求体
# get 和 delete 没有请求体

# 请求行（具体含义）
    # http 请求方法：大小写均可。
    # GET：查询。 —— 没有请求体
    # POST：添加。（登录时常用）
    # put: 修改。
    # delete: 删除。 —— 没有请求体
# 请求头（一些浏览器对象以及数据格式的需要设置）
    # 数据格式：k：v（键值对形式）
    # Content-Type：
        # application/json： JSON数据格式
        # application/x-www-form-urlencoded： form表单数据
# 请求体（请求携带的参数）
    # GET和DELETE 没有
    # PUT 和POST有
    # 数据类型受 Content-Type 值影响


# 请求 案例
#POST http://tpshop‐test.ceshiedu.net/index.php HTTP/1.1   请求头POST  url资源链接 http协议版本
# Host: tpshop‐test.ceshiedu.net     键值对形式的 请求头 一些前置设置
# Connection: keep‐alive
# Content‐Length: 53
# Accept: application/json, text/javascript, */*; q=0.01
# Origin: http://tpshop‐test.ceshiedu.net
# X‐Requested‐With: XMLHttpRequest
# User‐Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
# AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90
# Safari/537.36
# Content‐Type: application/x‐www‐form‐urlencoded; charset=UTF‐8
# Referer: http://tpshop‐test.ceshiedu.net/Home/user/login.html
# Accept‐Encoding: gzip, deflate
# Accept‐Language: zh‐CN,zh;q=0.9
# Cookie: is_mobile=0; province_id=1; city_id=2; district_id=3;
# is_distribut=1; PHPSESSID=1b80tii77mhle0fqd2bg52ucg5; cn=0

# username=13800138006&password=123456&verify_code=8888     请求体（请求携带的参数）


# HTTP响应
    # 服务器端，针对客户端发送的 http请求，回发响应数据。—— http应答！
    # 规定 回发给客户端的数据组织格式
# 整体格式
# 响应行（状态行）：协议版本 (空格) 状态码 (空格) 状态描述
# 响应头：语法格式：k:v
    # Content-Type: 描述 响应体中数据类型。
    # 空行：代表响应头结束
# 响应体：绝大多数不为空。（请求成功：回发数据，失败：回发错误信息）

# 数据类型受 Content-Type值影响
#状态行
# 状态码：
    # 1xx：代表指示信息。表请求已经被接收，等待继续处理。
    # 2xx：代表请求成功被处理、接收。 常见：200、201
    # 3xx：重定向，待访问的资源，需求重新指定路径访问。
    # 4xx：代表客户端错误。常见：404、 403
    # 5xx：访问器端错误。
# 状态码描述：一般与状态码 唯一对应。 200 —— ok； 404 —— file not found
# 响应头
# 语法格式：k：v
    # Content-Type：值为 响应体 的数据类型。
    # Content-Length: 响应体的大小。可以不写，浏览器会自动求取。一旦写，必须准确！
# 响应体
    # 回发给客户端的 消息内容。常见的有 html网页、xml、json


# URL 统一资源定位符
# 例子：http://www.itceshi.cn:8080/news/index.html?uid=123&page=1
# 格式如下
# 协议：http
# 域名：www.itceshi.cn
# 端口号：8080（ 不是默认，只不过网络 网络通信常用！）
# 资源路径：/news/index.html
# 查询参数：uid=123&page=1


# 传统风格接口
    # 特点：
    # 请求方法，只使用 get 和 post 即可。
    # URL 不唯一。同一个操作可以对应不同的 URL
    # 状态码的使用较单一。200 最常见。

# RESTful风格接口
# 特点：
    # 1. 每一个URL代表一种资源；
    # 2. 客户端和服务器之间，传递这种资源的某种表现层；
        # 表现层：数据的不同表现形式（如：图片、文字表现同一个数据对象）
    # 3. 客户端通过四个HTTP动词（GET、post、delete、put），对服务器端资源进行操作，实现"表现层状态转化"；
    # 4. 接口之间传递的数据最常用格式为JSON


# 接口测试流程
# 1. 分析需求，产生需求文档（产品）。
# 2. （开发产生接口文档）解析接口文档。（提取 http （协议）的请求、响应内容）
# 3. 产生 接口测试用例（送审）。
# 4. 执行 测试用例    postman 现使用 postman具有手动以及自动接口测试功能
    # 工具：postman、jmeter、fidller
    # 代码：python + Requests +UnitTest
# 5. 提交、跟踪缺陷。
# 6. 生成 测试报告。
# 7. （可选）接口自动化持续集成！



# 接口文档  由开发人员编写，描述接口信息的文档。开发团队按接口文档进行开发工作，并要一直维护遵守
# 作用
    # 1. 能够让前端开发与后台开发人员更好的配合，提高工作效率。（有一个统一参考的文件）
    # 2. 项目迭代或者项目人员更迭时，方便后期人员查看和维护
    # 3. 方便测试人员进行接口测试
# 展现形式
    # word 文档形式
    # Excel 表格式形式
    # pdf 文档形式

# 结构   postman 进行接口测试，所根据的就是 接口文档的各个层次信息进行接口测试
# 基本信息：
    # 资源路径 （协议和域名在 “系统信息”中）
    # 请求方法
    # 接口描述
# 请求参数：
    # 请求头：
    # Content-Type。描述请求体的数据类型！
    # 请求体：
    # 实现该接口使用的 数据及对应类型。
# 返回数据：
    # 状态码 200
    # 错误码（自定义状态码）
        # 码值
        # 描述信息

# 注意 协议中的状态码是同意规定的，必须遵守和使用，除此之外，我们也可以设置自己的状态码，来标识一些东西，但两者是不一样的

# 接口文档解析
# 接口文档的解析本质：从接口文档中，找出 http 请求所需要的 数据信息。
# 主要包含：请求方法、URL 、请求头、请求体、响应状态码、描述

# 个人理解就是 根据上述的接口结构，在接口文件中进行查找对应数据
# （ 基本信息、请求参数、返回数据 都是一个 客户端发起请求（基本信息、请求数据：（请求所携带的数据），服务端响应其数据(返回数据)是一个的完整接口构成链，如登录）
# 其接口构成了多个测试用例（正确的、错误的）

# 而 接口测试 就是 对客户端与服务端响之间产生的请求、响应 进行一个测试（客户端、服务端 意为模块、系统... ）
# 在接口测试的说明中 也表明了这个原因（第一行）

# 今日学习目标
# 分析接口文档，设计编写接口测试用例
# 使用Postman设置请求方法、URL、请求头、请求体，向接口发送http请求，并查看响应数据
# 接口用例设计
# 为什么写
    # 1. 防止测试点漏测。条理清晰
    # 2. 方便分配工作，评估工作量和时间
    # 3. 面试时使用！
# 接口测试的测试点
    # 测试点称之为测试维度。

    # 功能测试
        # 单接口功能：
            # 手工测试中的单个业务模块，一般对应一个接口。
            # 登录业务 ——> 登录接口
            # 加入购物车业务 ——> 加入购物车接口
            # 订单业务 ——> 订单接口
            # 支付业务 ——> 支付接口
        # 借助工具、代码。绕开前端界面，组织接口所需要的数据，展开接口测试。

        # 业务场景功能：
            # 按照用户实际 使用场景，梳理 接口业务 场景。
            # 组织业务场景时，一般只需做 正向 测试即可（与手工一致）。
            # 一般建议用最少的 用例 覆盖最多的业务场景。
            # 如 ：登录 —— 搜索商品 —— 加购物车 —— 下单 —— 支付 —— 评价

            # 对接口（系统或模块） 的完整的执行（业务）流程  进行测试且只做正向（正常执行，数符合规定的标准，
            # 不做错误验证，测试系统（接口）能达到想要的需求 如登录））
    # 性能测试
        # 响应时长
        # 吞吐量
        # 并发数量
        # 服务器资源利用率
    # 安全测试
        # 攻击安全。 —— 与测试工程师无关。
        # 业务安全。 —— 测试的方向。
            # 敏感数据是否加密
            # SQL注入：在用户能输入数据的位置，写入SQL语句。
            # SQL注入安全，用户恶意写入的SQL语句，不会执行，查询数据库


# 单接口测试用例
# 手工 测试用例文档 8 大要素：
    # 编号、用例名称（标题）、模块、优先级、预置条件、测试数据、操作步骤、预期结果
# 接口 测用例文档 10 要素：
    # 编号、用例名称（标题）、模块、优先级、预置条件、请求方法、URL、请求头、请求体(请求数据)、预期结果

# 分析接口文档 提取如下信息。最后填入 # 接口 测用例文档 10 要素中 构成 接口测试用例文档（有正向（成功），反向（失败），与功能测试 意思差不多）
# 基本信息：
    # 资源路径 （协议和域名在 “系统信息”中）
    # 请求方法
    # 接口描述
# 请求参数：
    # 请求头：
    # Content-Type。描述请求体的数据类型！
    # 请求体：
    # 实现该接口使用的 数据及对应类型。
# 返回数据：
    # 状态码 200
    # 错误码（自定义状态码）
        # 码值
        # 描述信息

#以 “登录接口” 为例：
# 请求方法：post
# URL： “系统信息” 中的 协议和域名 +/api/v1/pri/user/login
# 请求头：Content-Type : application/json
# 请求体：{"mobile":"13800000002","password":"123456"}
# 预期结果： {"success":true,"code":10000,"message":"操作成功！","data":"f5050a1b-7919-444c-9ec4-
# 3c1a7286536d"}
# data：值为登录成功生成的 令牌数据。该数据 会定时变化

# 提取信息 填入 接口 测用例文档 10 要素中

